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La pr6sente invention se rapporte a un precede de s6curisation de 
5 i'execution d'un programme informatique et a une entite electronique securisee 
mettant en oeuvre un tel proced6. 

Uinvention peut notamment etre utiiisee pour securiser une carte 
a microcircuit (autrement appelee "carte & puce"). 

Dans la suite de ce document, on entendra par « securisation » 
10 d'un programme informatique : 

- la detection d'attaques mal intention nees visant & modifier le 
comportement normal d'un programme informatique ; mais aussi 

- tout traitement visant a fiabiliser le deroulement d'un programme 
informatique, et notamment celui d'un programme s'executant dans un 

15 environnement tres perturbe, comme un satellite, ou celui d'un programme 
informatique a forte exigence de fiabilite, comme, par exemple, un programme 
de controle d'un implant cardiaque. 

Par ailleurs, on entendra par "programme informatique", tout 
programme, quel que soit le langage informatique et les moyens d& 

20 memorisation utilises. Par exemple, et de fagon non limitative, le programme 
informatique peut etre ecrit en langage machine, assembleur, C, C++, Java, 
VHDL. Le programme peut etre memorise dans une m6moire permanente, par 
exemple dans une memoire ROM ou EEPROM ou sur un disque dur, ou dans 
une memoire volatile, par exemple de type RAM. Le programme peut etre 

25 egalement materialise par un circuit integre, par exemple de type FPGA ou par 
un circuit ASIC ( Application Specific Integrated Circuit ). 

La presente invention permet la detection d'une attaque destinee 
a modifier le deroulement de I'ex^cution d'un programme informatique 
s'ex6cutant sur une entite electronique s6curis6e, par exemple une carte a 

30 microcircuit, une carte PCMIA securisee (par exemple une carte IBM4758), une 
clef USB ou un passeport integrant une puce sans contact dans une de ses 
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pages. Elle permet aussi le declenchement d'une contre-mesure a cette 
attaque. 

La presente invention permet, en particulier, de detecter des 
attaques par perturbation du fonctionnement d'une entite electronique, par 
5 exemple les attaques de type « attaques par generation de fautes » (en anglais 
"Fault Attack"). 

Ces attaques visent a modifier illicitement le contenu ou la lecture 
du contenu d'un registre, d'une memoire ou d'un bus, ou £ obliger un 
processeur a ne pas, ou mal, executer certaines instructions d f un programme 
10 informatique. Le programme informatique attaque peut alors se derouler d'une 
fagon tres differente de celle qui avait ete pr6vue au moment de sa conception. 

Ces attaques peuvent, entre autres et de fagon connue, etre 

effectuees : 

- en generant un pic de tension & Tune des bornes d'alimentation 
15 du processeur ; 

- en elevant brusquement sa temperature ; 

- en changeant rapidement sa frequence d'horloge ou sa tension 
d'alimentation ; 

- en appliquant un flash de lumiere, un rayon laser, ou un champ 
20 electromagnetique, sur une partie du silicium qui le compose. 

Selon Tetat actuel de la technique, I'homme du metier dispose de 
differents moyens pour securiser un programme informatique, et notamment 
pour lutter contre les attaques par generation de fautes dans une carte a 
microcircuit. 

25 Une premiere methode consiste a installer, dans les composants 

des cartes 3 microcircuit, des capteurs qui permettent de detecter de telles 
attaques. 

Uefficacite d'une telle methode est neanmoins restreinte car il est 
en pratique impossible de mettre des capteurs sur toute la surface de ce 
30 composant. Par ailleurs ces capteurs 6tant egalement composes de silicium, il 
est egalement possible de les perturber ou de modifier les informations qu'ils 
transmettent. 
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Un deuxieme procede de securisation connu et mis en oeuvre 
dans la plupart des systemes d'exploitation des cartes a microcircuit repose sur 
I'utilisation de "semaphore". Un tel procede comporte : 

-une etape de modification du contenu d'une zone memoire 
5 durant ['execution d'un ensemble d'instructions critiques ; et 

-une etape de verification au cours de laquelle on v6rifie, en lisant 
le contenu de la zone m6moire precitee, que I'etape de modification precitee a 
et6 realisee. 

Si la zone memoire n'a pas ete modifiee, cela signifie que I'etape 
10 de modification n'a pas ete effectuee, et que, par consequent, les instructions 
critiques precitees n'ont pas ete correctement executees. 

On notera que le terme "semaphore" fait reference dans le present 
document a une notion differente de celle connue dans le domaine de !a 
programmation des processus concurrents, et qui porte neanmoins le meme 
15 nom. 

Cette deuxieme methode dont la mise en oeuvre s'effectue par 
logiciel ne pr6sente pas les inconvenients de la premiere methode precitee. > : » 

Neanmoins,. et de fa?on connue, les semaphores sont 
traditionnellement implementes par des variables residant en memoire^de 
20 travail (RAM) et leur manipulation (positionnement, lecture) est relativement 
lente ou couteuse en espace memoire. Cette contrainte est particulierement 
penalisante lorsque le programme s'execute sur des systemes disposant de 
ressources limitees (memoire, puissance de calcul, ...) tels que des cartes a 
puce. La presente invention vise une methode de securisation logicielle ne 
25 presentant pas les inconvenients precedents. 

A cet effet, elle concerne un procede de securisation de 
Texecution d'un programme informatique, ce proced§ comportant : 

- une etape d'empilement d'une valeur pred§termin§e dans une 
pile d'instructions du programme ; et 
30 - une etape de d£pilement de cette pile, cette etape de depilement 

6tant adaptee, le cas echeant, a permettre la detection d'une anomalie 
d'execution. 
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On rappellera ici qu'une pile ^instructions est une zone de la 
memoire pour conserver provisoirement des donnees. Les valeurs sont 
empires dans la pile et d6pil6es aux moyens de deux instructions specifiques, 
respectivement appelees PUSH et POP dans la suite de la description. 
5 Ces instructions ne manipulent que des valeurs de taille fixe, par 

exemple d'un octet. 

Utilisation de la pile suit un algorithme de type LIFO ("Last In 

First Out"). 

De fagon connue, elle memorise, en particulier, Padresse de retour 
10 d'une procedure (instruction RET en assembleur 80x86, par exemple). 

Le proc6de de securisation selon ['invention utilise done la pile 
d'execution pour memoriser une valeur permettant la detection d'une anomalie 
d'execution. 

Une pile d'execution etant, d'une part d'acces rapide en lecture et 
15 ecriture et, d'autre part, peu couteuse en espace memoire, le procede de 
securisation selon Pinvention est particulterement adapte pour securiser des 
programmes informatiques s'executant sur des systemes disposant de 
ressources limitees. 

Cette utilisation nouvelle de la pile destructions presente d'autres 
20 avantages qui seront d6crits ulterieurement 

Dans un mode prefere de realisation, les 6tapes d'empilement et 
de depilement sont respectivement associees a des elements d'au moins un 
sous-ensemble destructions dudit programme. 

Par exemple, Petape d'empilement peut etre associee a 
25 Instruction "open(fichier)" d ! ouverture d'un fichier et Petape de depilement a 
^instruction "close(fichier)" de fermeture de ce fichier. 

Cette caracteristique est particulierement avantageuse, car elle 
permet d'automatiser P6criture des instructions de securisation, en associant, 
par exemple a Paide d'un 6diteur, les operations d'empilement et de depilement 
30 aux elements precites, £ savoir dans Pexemple precedent, les instructions 
"open" et "close". 



ler uepui 



5 



Selon une premiere variante de ce mode prefere de realisation, 
les elements du sous-ensemble destructions sont respectivement une 
parenthese ouvrante et une parenthese fermante d'un systeme de parentheses. 

On rappelle a cet effet, qu'en theorie des langages, et de fagon 
5 connue par Thomme du metier des langages informatiques, on dit que Ton se 
trouve en presence d' un systeme de parentheses lorsqu'un texte comporte 
autant de parentheses ouvrantes que de parentheses fermantes et que tout 
debut de ce texte contient un nombre de parentheses ouvrantes superieur ou 
egal au nombre de parentheses fermantes. 
10 Selon cette caracteristique particulterement avantageuse, les 

etapes d'empilement et de depilement peuvent respectivement §tre associees 
aux instructions : 

- "(" et ")" ; ou 

- T et "}" ;ou 

15 - "begin" et "end" ; ou I 

- "repeat" et "untiT\ 

Dans une autre variante de ce mode prefere de realisation, I'dtape 
de depilement est associ6e a une instruction de retour d'executioa du 
programme ou d'un sous-programme de ce programme. 

20 Cette caracteristique permet avantageusement d'utiliser les 

operations normales de depilement effectuees traditionnellement au retour d f un 
programme ou d'un sous programme (lors de Texecution de I'instruction return) 
pour detecter une anomalie d'execution, si les valeurs depilees a cette occasion 
ne correspondent pas a celles qui auraient du etre depilees an cas d'execution 

25 normale du programme. 

Selon une autre caracteristique, le programme est dans un 
langage de programmation qui comporte une premiere instruction dont 
Texecution met en oeuvre Tetape d ! empilement et/ou une deuxteme instruction 
dont ('execution met en oeuvre ladite etape de depilement. 

30 Dans ce mode de realisation, .des instructions nouvelles sont 

integrees au langage de programmation, ces instructions ayant chacune une 



fonction propre et, soit une fonction d'empilement, soit une fonction de 
depilement en vue de la securisation du programme. 

Pour reprendre I'exemple brievement introduit ci-dessus, une 
nouvelle instruction baptisee "open(fichier)'\ peut etre creee, cette nouvelle 
5 instruction permettant a la fois Pouverture du fichier et I'empilement d'une valeur 
predeterminee dans la pile destructions du programme. 

Ainsi, le programmateur est assure que des fonctions de 
securisation sont mises en oeuvre a chaque ouverture de fichier, sans meme 
qu'il ait besoin de s'en occuper et sans qu'un outil Jogiciel particulier soit 
1 0 necessaire. 

Preferentiellement, la deuxieme instruction termine le programme 
ou un sous-programme de ce programme. 

Ce mode de realisation presente les memes avantages que le 
mode de realisation introduit precedemment et dans lequel les instructions 
15 d'empilement et de depilement sont assoctees, et non pas integrees, a des 
elements d'un sous-ensemble destructions du programme. En consequence, il 
ne sera pas decrit en details ci-apres. 

Dans un mode prefere de realisation, la valeur predeterminee est 
representative d'un sous-ensemble destructions critiques du programme. 
20 Cette caracteristique est particulierement avantageuse lorsque le 

procede de securisation est utilise pour s6curiser plusieurs sous-ensembles 
destructions du programme. 

Elle permet de d6tecter, au cours de I'etape de depilement, qu'un 
sous-ensemble destructions particulier a ete execute correctement, et non pas 
25 un autre sous-ensemble destructions dont I'execution aurait entraTne 
Pempilement d'une autre valeur predeterminee. 

L'homme du metier comprendra aisement que cette 
caracteristique peut §tre utilisee pour s6curiser differentes branches d'un test 
(du type, "if, "then", "else" en langage C), une valeur predeterminee differente 
30 etant empilee dans chacune des branches, et I'etape de depilement 6tant 
effectuee a la fin de ce test. 
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Lorsque le programme fait appel a un sous-programme, cette 
caracteristique permet aussi de s'assurer, pendant I'execution de ce sous- 
programme, que Ton est entr§ dans ce sous-programme suite a cet appel et 
non pas suite a une attaque par generation de fautes. 
5 Deux exemples de mise en oeuvre de cette caracteristique seront 

detailles ulterieurement en reference aux annexes A et C. 

Selon une autre caracteristique, le proced6 de securisation selon 
I'invention comporte une etape de traitement d'anomalie, mise en oeuvre, si, au 
cours de I'etape de depilement, on depile une valeur differente de la valeur 
10 predetermined. 

Cette caracteristique permet avantageusement de mettre en 
oeuvre I'etape de traitement d'anomalie, des qu'une attaque a eu pour 
consequence de modifier I'execution normale du programme et notamment 
I'appel ou le retour d'execution d'une fonction de ce programme. Ce procede de 
15 securisation est alors particulierement efficace. 

Le traitement de I'anomalie peut par exemple, dans le cas de 
['utilisation du procede de securisation dans une carte a microcircuit, consister a 
rendre la carte inoperante, par destruction du systeme d'exploitation dejcette 
carte. • 

20 Trois exemples de mise en oeuvre de cette caracteristique seront 

detailles ulterieurement en reference aux annexes A, C et D. 

Dans un mode de realisation particulier dans lequel le programme 
comporte au moins un appel a un sous-programme, I'etape d'empilement est 
effectuee avant cet appel, et la" valeur predeterminee supprimee de la pile 
25 pendant I'execution de ce sous-programme. 

Cette caracteristique permet ainsi de contrdler que le sous- 
programme a effectivement ete execute et correctement execute. 

En effet, si I'appel a ce sous-programme a ete saute, ou si I'etape 
de depilement n'a pas ete effectuee, la pile destructions conservera la valeur 
30 predeterminee empilee. 

Le depilement ulterieur de cette valeur entraTnera la detection de 
I'anomalie d'execution, comme explicite infra en reference aux annexes B et C. 
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Dans ce mode de realisation particulier, la valeur predeterminee 
peut avantageusement etre I'adresse d'une fonction de traitement d'une 
anornalie. 

Ainsi, si le valeur pred6termin6e n ! est pas depilee pendant 
1'execution du sous-programme, par exemple suite a une attaque ayant pour 
consequence la non execution de ce sous-programme, le depilement ulterieur 
par le processeur de cette valeur entramera, la mise en oeuvre de cette fonction 
de traitement. Un exemple sera d§taille ulterieurement a i'annexe B. 

Cette caracteristique permet de declencher la fonction de 
traitement si le programme subit une attaque quelconque dont la consequence 
est d'eviter 1'execution du sous-programme. Elle est done particulierement utile 
pour securiser des fonctions critiques, par exemple une procedure 
d'authentification. 

Dans un autre mode de realisation particulier dans lequel le 
programme comporte au moins un appel a un sous-programme, I'etape 
d'empilement est effectuee pendant 1'execution du sous-programme, et la 
valeur predeterminee supprim6e apres execution de ce sous-programme. 

Cette caracteristique permet ainsi de controler que le retour de ce 
sous-programme s'effectue correctement. 

En effet, si le retour de ce sous-programme a ete perturbe, la pile 
destructions conservera la valeur predeterminee empilee. 

Ce mode de realisation particulier sera detaille en reference a 

Tannexe D. 

Dans cet autre mode de realisation particulier, la valeur 
predeterminee peut avantageusement §tre Tadresse d'une fonction de 
traitement d f une anomalie. 

Pour les raisons evoquees precedemment, cette caracteristique 
permet de declencher la fonction de traitement si le programme subit une 
attaque quelconque dont la consequence est d'eviter Texecution du sous- 
programme. Elle est done particulierement utile pour securiser des fonctions 
critiques, par exemple une procedure d'authentification. 
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Un exemple de mise en oeuvre de cette caracteristique sera 
donne en reference a I'annexe E. 

L'invention vise aussi un support d'informations lisible par un 
systeme informatique, eventuellement totalement ou partiellement amovibie, 
5 notamment CD-ROM ou support magnetique, tel un disque dur ou une 
disquette, ou support transmissible tel un signal electrique ou optique, ce 
support d'informations comportant des instructions d'un programme 
informatique permettant la mise ne oeuvre d'un proced<§ de securisation tel que 
decrit brievement ci-dessus, lorsque ce programme est charge et execute par 
10 un systeme informatique. 

L'invention vise egalement un programme d'ordinateur stocke sur 
un support d'informations, ce programme comportant des instructions 
permettant la mise en oeuvre d'un procede de securisation tel que decrit 
brievement ci-dessus, lorsque ce programme est charge et execute par un 
15 systeme informatique. 

L'invention vise egalement une entite electronique securisee et 
une carte & microcircuit comportant des moyens de mise en oeuvre d'un 
procede de securisation tel que decrit brievement ci-dessus. 

Les avantages et caracteristiques particulieres propres aux 
20 support d'information, au programme d'ordinateur et a la carte a microcircuit 
etant les memes que ceux exposes ci-dessus concernant le procede de 
securisation selon l'invention, ils ne seront pas rappeles ici. 

D'autres aspects et avantages de la presente invention 
apparaitront plus clairement a la lecture de la description de modes particuliers 
25 de realisation qui va suivre, cette description etant donnee uniquement a titre 
d'exemple non limitatif et faite en reference aux annexes A a E qui comportent 
cinq exemples de programmes informatiques securises conformement a 
l'invention. 

Ces programmes sont ecrits en langage C et en assembleur 
30 80c51. Afin d'en faciliter la description, chaque ligne est precedee d'un 
commentaire compris entre les chames de caracteres "/*" et "*/". 
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La description d'une carte a microcircuit conforme a Tinvention 
dans un mode prefer^ de realisation sera effectuee en reference & la figure 1 . 

L'annexe A comporte 33 lignes d'instructions numerotees /*a17 a 
/*a337 d'un programme informatique dont I'execution est securisee par un 
5 precede de securisation conforme a Pinvention dans un mode prefere de 
realisation. 

La ligne /*al*/ n'est pas une instruction a proprement parler. Elle 
symbolise le fait que le programme de I'annexe A peut contenir un certain 
nombre d'instructions, en lieu et place de la chaine de caracteres en plus 
10 des instructions servant a la securisation de ce programme. Elle repr§sente un. 
ensemble d'instructions sans rapport avec la presente invention. 

La ligne /*a2*/ comporte une directive #pragma asm, indiquant au 
compilateur que les lignes d'instructions qui suivent sont en assembleur 80c51. 

La ligne /*a3*/ comporte une instruction dont I'execution met en 
15 oeuvre une etape d'empilement de la valeur predetermine 0 (en notation 
hexadecimale) dans la pile d'instructions du programme de I'annexe A. Pour 
simplifier, on dira par la suite qu'on empile la valeur 0 a la ligne /*a37. 

Puis, on empile la valeur 1 a la ligne /*a4*/. 

Dans le mode prefere de realisation d^crit ici, les valeurs 
20 predetermines OOh et 01 h represented respectivement les octets de poids fort 
et de poids faible de la valeur 1 (en notation hexadecimale) codee sur 2 octets. 

La ligne /*a5*/ comporte une directive #pragma endasm, indiquant 
au compilateur que les lignes d'instructions qui suivent ne sont plus en 
assembleur 80c51, mais en langage C. 
25 Les lignes /*a67 et /*a7*/ similaires a la ligne /*a1*/ precedemment 

decrite, represented un ensemble d'instructions sans rapport avec la presente 
invention. 

La ligne /*a8*/ comporte une instruction au cours de laquelle on 
teste si le contenu de la variable "test" est egal a "VRAI". De fagon connue, si 
30 tel est le cas au moment de I'execution du programme de I'annexe A, le 
processeur executera les instructions /*a97 a /*a23*/ suite au test de la ligne 
/*a87. 
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Sinon, il executera directement I'instruction de la ligne /*a24*/. 

La ligne /*a9*/ est Identique a la ligne /*a27 precedemment 

decrite. 

Les lignes /*a10*/ et /*a11*/ sont similaires aux lignes /*a37 et 
5 /*a4*/ deja decrites. Elles permettent d'empiler en deux temps la valeur 1 (en 
notation hexadecimale) codee sur deux octets. 

La ligne /*a12*/ est identique a la ligne /*a57 precedemment 

decrite. 

Les lignes /*a13*/ et /*a147 similaires a la ligne /*a1*/ 
10 precedemment decrite, represented un ensemble d'instructions sans rapport 
avec la presente invention. Ces instructions peuvent bien entendu manipuler la 
pile d'instructions, a condition de laisser cette pile d'instructions, a Tissue de la 
ligne /*a14*/ dans I'etat ou elle se trouvait avant ['instruction /*a13*/. 

La ligne /*a15*/ est identique a la ligne /*a2V precedemment 

15 decrite. 

La ligne /*a167 comporte une instruction dont I'execution met en 

ceuvre une etape de depilement de la pile d'instructions, la valeur depilee etant 

memorisee dans un registre A. Pour simplifies on dira par la suite qu'on .depile 

dans le registre A a la ligne /*a167. I 
20 A Tissue de I'instruction /*a167, le registre A memorise en 

consequence la derniere valeur empilee dans la pile, celle-ci fonctionnant selon 

un mecanisme LIFO. 

La ligne /*a177 comporte une instruction permettant de comparer 

le contenu du registre A avec la valeur 02H. Normalement, si le programme n'a 
25 pas subi d'attaque lors de son execution depuis la fin de I'instruction de la ligne 

/*a11*/, le contenu du registre A contient la valeur 02H empilee au cours de 

I'instruction de la ligne /*a1 1*/. 

L'etape de depilement de la ligne /*a167 permet ainsi la detection 

d'une anomalie d'execution, conformement a la presente invention. 
30 Si, au cours de Tetape de comparaison de la ligne /*a177 on 

trouve que la valeur du registre A est differente de la valeur 02H, le programme 
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de ['annexe A se branche a I'adresse "anomalie" au cours de I'instruction de la 
ligne /*a1 87. 

Cette adresse "anomalie" est, dans le mode de realisation decrit 
ici, I'adresse d'une etape de traitement d'anomalie du procede de securisation 
5 selon invention. Dans la pratique, I'adresse "anomalie" est une adresse en 
notation hexadecimale directement interpretable par le processeur. 

En revanche, si, au cours de I'etape de comparaison de la ligne 
/*a177 on trouve que le registre A memorise la valeur 02H, le programme de 
I'annexe A execute I'instruction de la ligne /*a197. 
10 Les lignes /*a197 a /*a217 sont des lignes similaires aux lignes 

/*a167 a /*a187 precedemment decrites : 

- depilement dans le registre A a la ligne /*a19*/ ; 

- comparaison du registre A, avec la valeur 00H a la ligne /*a207, 
la valeur 00H correspondant a la valeur predeterminee empilee a la ligne 

15 /*a107;et 

- branchement a I'adresse "anomalie" au cours de I'instruction de 
la ligne /*a217 si le registre A ne contient pas la valeur 0OH au moment de 
I'execution de I'instruction de la ligne /*a207. 

En revanche, si le registre A contient la valeur 00H, le programme 
20 execute I'instruction de la ligne /*a227 identique a la ligne /*a57 precedemment 
decrite. 

Les lignes /*a247 et /*a257 similaires a la ligne /*a17 
precedemment decrite, represented un ensemble d'instructions sans rapport 
avec la presente invention. 

25 Les lignes /*a267 a /*a337 sont des lignes similaires aux lignes 

/*a157 a /*a227 precedemment decrites : 

Elles comportent des etapes /*a287 et /*a307 de depilement 
permettant de detecter une anomalie d'ex6cution du programme si la pile a 6te 
corrompue et qu'elle ne contient pas, juste avant I'execution de I'instruction de 

30 la ligne /*a27*/ les valeurs predetermines 01 H et 00H empilees respectivement 
aux lignes /*a47 et /*a37. 
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En conclusion, les deux sous-ensembles destructions, 
respectivement constitues par les lignes /*a67 a /*a25*/ et /*a137 a /*a14*/ sont 
securises. 

Le sous-ensemble destructions constitue par les lignes /*a6*/ et 
5 /*a257 est securise grace : 

-a I'etape cTempiiement (lignes /*a37 et /*a4*/) de la valeur 
predeterminee 1 codee sur 2 octets ; et 

- a I'etape de d6pilement des lignes /*a27*/ et /*a307. 

De meme, le sous-ensemble destructions constitue par les lignes 
10 /*a1 3*/ et /*a147 est securise grace : 

-a I'etape d'empilement (lignes /*a107 et /*a11*/) de la valeur 
predeterminee 2 codee sur 2 octets ; et 

- a I'etape de depilement des lignes /*a16*/ et /*a19*/. 

Cette implementation n'est nullement limitative, les valeurs 
15 pred6terminees 1 et 2 auraient aussi pu §tre identiques ou choisies de fagon 
aleatoire. 

Uannexe B comporte 28 lignes destructions numerotees /*b17 a 
/*b28*/ d'un programme informatique dont !'ex§cution est securisee par un 
procede de securisation conforme a invention dans un mode prefe,re de 
20 realisation. 

Les lignes /*b1*/ et/*b27 constituent les deux premieres lignes de 
declaration de la fonction "function" en langage C, cette fonction ne comportant 
ni parametre d'entree ni valeur de retour. La ligne /*b117 comporte la derniere 
instruction de la declaration de cette fonction. 

25 La ligne /*b37 similaire a la ligne /*a17 precedemment decrite en 

reference a I'annexe A, represente un ensemble destructions sans rapport 
avec la presente invention. 

La ligne /*b47 est identique a la ligne /*a27 precedemment decrite 
en reference a I'annexe A. 

30 Au cours des instructions des lignes /*b57 et /*b67, on effectue, 

en deux temps, une etape d'empilement d'une valeur predeterminee codee sur 
deux octets, cette valeur predetermine etant, dans ce mode pref6re de 



14 



realisation I'adresse d'une fonction OS_kiilcard de traitement d'une anomalie. 
Dans la pratique, I'adresse "OSJdllcard" est une adresse en notation 
hexadecimale directement interpretable par le processeur. 

Dans le cas de I'utilisation du procede de securisation dans une 
carte a microcircuit, la fonction OS_killcard peut par exemple inhiber le 
fonctionnement de la carte par destruction de son systeme d'exploitation. 

La ligne /*b7*/ est identique a la ligne /*a5*/ precedemment decrite 
en reference a l'annexe A. 

La ligne /*b8*/ similaire a la ligne /*a1*/ precedemment decrite en 
reference a l'annexe A, represente un ensemble destructions sans rapport 
avec la presente invention. 

La ligne /*b9*/ comporte une instruction d'appel 3 une fonction 
critique "fonction_critique", dont le code sera decrit en reference aux lignes 
/*b127a/*b287. 

De fagon connue, I'appel a un sous-programme entraTne 
automatiquement I'empilement de I'adresse de retour de ce sous-programme 
dans la pile destructions. Cette adresse de retour, codee sur 2 octets, occupe 
done deux registres de la pile. Dans I'exemple decrit ici, cette adresse 
correspond a I'adresse de I'instruction de la ligne /*b10*/, cette ligne devant etre 
executee au retour de la fonction "fonction_critique". 

Les lignes /*b12*/ et /*b13*/ d'une part et /*b28*/ d'autre part 
constituent les deux premieres lignes et la demtere ligne de declaration de la 
fonction "fonction_critique", cette fonction ne comportant ni parametre d'entree 
ni valeur de retour. 

Apres I'execution des instructions des lignes /*b127 et /*b137, les 
quatre dernieres valeurs empilees dans la pile destructions sont, dans I'ordre 
chronologique : 

- I'octet de poids fort de I'adresse de la fonction OS_killcard (ligne 

/*b57) ; 

- I'octet de poids faible de I'adresse de la fonction OS_killcard (ligne 

/*b67) ; 
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- I'octet de poids fort de Padresse de la premiere instruction de la 
Iigne/*b10*/; et 

- I'octet de poids faible de I'adresse de la premiere instruction de la 
ligne /*t>10*/. 

5 La ligne /*b14*/ similaire a la ligne /*a17 precedemment decrite en 

reference a I'annexe A, represente un ensemble d'instructions sans rapport 
avec la presente invention. 

De m§me que decrit precedemment en reference aux lignes 
/*a137 et /*a14*/ de I'annexe A, on supposera que ces instructions laissent la 
1 0 pile d'instructions, dans I'etat ou elle se trouvait avant I'instruction /*b147. 

La ligne /*b15*/ est identique a la ligne /*a2*/ precedemment 
decrite en reference a I'annexe A. 

A la ligne /*b167, on depile la pile d'instructions dans le registre A, 
le contenu de ce registre A etant ensuite sauvegarde dans un registre R7 a 
15 I'etape/*b177. 

De meme, a la ligne /*b187, on depile a nouveau la pile 
d'instructions dans le registre A, le contenu de ce registre A etant sauvegarde 
dans un registre R6 a I'etape /*b1 97. 

Avec ce qui a ete dit precedemment, et en cas d'execution 
20 normale du programme de I'annexe B, les registres R6 et R7 contiennent done 
respectivement, a Tissue de I'execution de I'instruction de la ligne /*b197 : 

- I'octet de poids fort de I'adresse de la premiere instruction de la 
ligne /*b1 07 ; et 

- I'octet de poids faible de I'adresse de la premiere instruction de la 
25 ligne /*b1 07 

Ensuite, on depile deux fois dans le registre A, la pile 
d'instructions aux lignes /*b207 et /*b217, ce qui revient, en cas d'execution 
normale du programme de I'annexe B, a supprimer I'adresse sur deux octets de 
la fonction OS_killcard de la pile d'instructions pendant I'execution du sous- 
30 programme "fonction_critique". 

A la ligne /*b227, on memorise dans le registre A, le contenu du 
registre R6, a savoir I'octet de poids fort de la premiere instruction de la ligne 
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/*t>10*/, cette valeur etant empilee dans la pile destructions a Petape de la ligne 
/*b23*/. 

De fagon identique, on empile Poctet de poids faible de la premiere 
instruction de la ligne /*b10*/, cet octet etant memorise dans le registre R7, aux 
lignes /*b24*/ et /*b25*/. 

La ligne /*b26*/ est identique & la ligne /*a5*/ precedemment 
d6crite en reference a Pannexe A. 

La ligne /*b27*/ similaire & la ligne /*a1*/ precedemment decrite en 
reference a Pannexe A, represente un ensemble destructions sans rapport 
avec la presente invention. 

La ligne /*b28*/ est la derniere ligne du sous-programme 
"fonction_critique". De fagon connue, elle se traduit en assembleur par une 
instruction de type "RETURN" ou "RET" dont Pexecution entrame le saut du 
programme a Padresse m6morisee dans les deux premiers registres de la pile 
destruction. 

S'il ne subit pas d'attaque lors de son execution, le programme se 
branche done a la premiere instruction de la ligne /*b10*/, Padresse de cette 
instruction ayant ete empi!6e aux lignes /*b23*/ et /*b25*/ 

La ligne /*b10*/ similaire a la ligne /*a1*/ precedemment decrite en 
reference a Pannexe A, represente un ensemble destructions sans rapport 
avec la presente invention. 

La ligne /*b1 1*/ termine la fonction "function". 

En conclusion, dans le mode de realisation particulier de Pannexe 
B, Petape d'empilement de Padresse de la fonction OS_kilIcard est effectuee 
avant Pappel au sous-programme "fonction_critique", cette adresse etant 
supprim£e de la pile pendant Pex6cution de ce sous-programme, aux lignes 
/*b20*/ et /b21*/ 

Ce mode de realisation permet ainsi de controler que le sous- 
programme "fonction_critique" a 6te effectivement execute. 

Par exemple, si Pappel a ce sous-programme a 6te perturb£, ou, 
plus generalement, si Petape de depilement n ! a pas ete effectuee, la pile 
destructions conservera la valeur de la fonction OS_killcard, le depilement 
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ulterieur de cette valeur, par exemple lors d'une instruction de retour 
d'execution, entrainant la detection de cette anomalie d'execution, et I'execution 
de la fonction OS_killcard de traitement d'une anomalie. • 

L'annexe C comporte 32 lignes d'instructions numerotees /*c1*/ a 
5 /*c32*/ d'un programme informatique dont I'execution est securisee par un 
proc<§de de securisation conforme a invention dans un mode prefere de 
realisation. 

Les lignes /*c17 a /*c11*/ sont similaires aux lignes /*b1*/ a /*b1 1*/ 
decrites en reference a l'annexe B, a la difference pres que I'on empile dans la 
10 pile destruction, la valeur predeterminee 05F1H codee en hexadecimal sur 
deux octets, au lieu de I'adresse de la fonction OS_killcard (lignes /*c5*/ et 
/*c6*/). 

Cette etape d'empilement est la aussi effectuee avant I'appel au 

sous-programme fonction_critique. 
15 Dans ce mode de realisation particulier, cette valeur 

predeterminee 05F1H est representative du sous-ensemble constitue par les 

instructions des lignes /*c1 2*1 a /*c1 9*/. . ■ }• 

Les lignes /*c12*/ a /*c19*/ sont similaires aux lignes /*W2*/ a 

/*b19*/ decrites en reference a l'annexe B. ..\ 
20 En cas d'execution normale du programme de l'annexe C, les 

registres R6 et R7 contiennent done respectivement, a Tissue de I'execution de 

I'instruction de la ligne /*c19*/, I'octet de poids fort et I'octet de poids faible de 

I'adresse de la premiere instruction de la ligne /*c10*/ correspondant a I'adresse 

de retour de la fonction "fonction_critique". 
25 On depile ensuite la pile d'instructions dans le registre A a la ligne 

/*c207, le contenu de ce registre etant ensuite compare avec la valeur 

hexadecimale F1H a la ligne /*c21*/. 

Normalement, si le programme n'a pas subi d'attaque, notamment 

au moment de I'appel a la fonction "fonction_critique", le registre A contient la 
30 valeur F1 H empilee au cours de I'instruction de la ligne /*c5*/. 

L'etape de depilement de la ligne /*c20*/ permet ainsi la detection 

d'une anomalie d'execution, conformement a la presente invention. 
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Si, au cours de Petape de comparaison de la ligne /*c217 on 
trouve que la valeur du registre A est differente de la valeur F1H, le programme 
de Pannexe C se branche a Padresse "OS_killcard" au cours de instruction de 
la ligne /*c227. Cela peut notamment se produire a la suite d'une attaque par 
5 generation de faute qui entrainerait PexScution de (a fonction n fonction_critique M 
sans qu'elle ait 6te appelee. 

Dans ce mode de realisation du procede de securisation selon 
Tinvention, le programme de traitement d'anomalie OSJdllcard est done mis en 
oeuvre, si, au cours de Petape de depilement de Instruction /*c20*/, on depile 
10 une valeur differente de la valeur pred6terminee F1H empilee a ('instruction 
/*c6*/. 

En revanche, si, au cours de Petape de comparaison de la ligne 
/*c217 on trouve que le registre A memorise la valeur F1H, le programme de 
Pannexe C execute instruction de la ligne /*c23V. 
15 Les lignes /*c237 a /*c257 sont des lignes similaires aux lignes 

/*c207 a /*c227 precedemment decrites : 

- depilement dans le registre A a la ligne /*c237 ; 

- comparaison du registre A, avec la valeur 05H a la ligne /*c247, 
la valeur 05H 6tant la valeur predeterminee empil6e a la ligne /*c57 ; et 

20 - branchement £ Padresse "OSJdllcard" au cours de instruction 

de la ligne /*c25*/ si le registre A ne contient pas la valeur 05H au moment de 
['execution de instruction de la ligne /*c25*/. 

En revanche, si le registre A contient la valeur 05H, le programme 
execute instruction de la ligne /*c267. 
25 Quoiqu'il en soit, Pexecution des instructions des lignes /*c207 et 

/*c23*/ supprime la valeur predetermine 05F1H de la pile d'execution. 

Les lignes /*c267 a /*c297 sont similaires aux lignes /*b227 a 
/*b25*/ precedemment decrites en reference a Pannexe B. 

Elles permettent d'empiler dans la pile destructions les valeurs 
30 memorisees dans les registres R6 et R7 lors de Pexecution des instructions des 
lignes /*c177 et /*c197, a savoir respectivement : 
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- Poctet de poids fort de Padresse de la premiere instruction de la 
ligne /*c10*/ ; et 

- Poctet de poids faible de Padresse de la premiere instruction de la 
ligne /*c10*A 

5 Les lignes /*c30*/ a /*c32*/ sont simiiaires aux lignes /*b26*/ a 

/*b28*/ precedemrnent decrites en reference a Pannexe B. 

S'ii n r y a pas eu d'attaque, le programme se branche done a la 

premfere instruction de la ligne /*c10*/, Padresse de cette instruction ayant ete 

empilee aux lignes /*c277 et /*c29*/ 
10 La ligne /*c10*/ similaire a la ligne /*a17 precedemrnent decrite en 

reference d Pannexe A, represente un ensemble ^instructions sans rapport 

avec la presente invention, et la ligne /*c11*/ termine la fonction "functionl" de 

Pannexe C. 

Dans ce mode de realisation, la valeur 05F1H aurait pu etre 
15 Padresse d'une fonction de traitement d'anomalie. Ce mode particulier de 
realisation permet de renforcer la securisation du programme, car m§me;si une 
attaque se produit au cours de Pexecution du test des lignes /*c207 a /*c25*/, 
cette attaque serait detectee par la mise en oeuvre ulterieure de cette function 
de traitement d'anomalie. 
20 En variante, plusieurs adresses de fonctions de traitement 

d'anomalie peuvent etre utilisees, chacune d'entre elles 6tant une valeur 
pnSdeterminee assoctee a un ensemble destructions critiques. 

L'annexe D comporte 32 lignes destructions numerotees /*d1*/ a 
/*d327 d'un programme informatique dont Pex6cution est securisee par un 
25 procede de securisation conforme 3 Pinvention dans un mode pr6fere de 
realisation. 

Dans ce mode de realisation particulier, le programme comporte, 
a la ligne /*d4*/, un appel a un sous-programme M fonction_critique ! \ 

Cet appel entrame automatiquement Pempilement de Padresse de 
30 retour de ce sous-programme, & savoir Padresse de Pinstruction de la ligne 
/*d57. 
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Au cours des instructions des lignes /*d20*/ a /*d23*/ du sous- 
programme M fonction_critique", on memorise dans les registres R6 et R7 les 
premieres valeurs de la pile destructions, a savoir I'adresse de retour, codee 
sur deux octets, de ce sous-programme. 

Puis, on empile la valeur predeterminee 05F1H aux lignes /*d24*/ 

et /*d25*/. 

On notera que dans ce mode de realisation, cette etape 
d'empilement est effectuee pendant Pexecution du sous-programme 
,? fonction_critique". 

Enfin, on empile, au cours de Pexecution des instructions des 
lignes /*d27*/ et /*d297, le contenu des registres R6 et R7, ces registres 
contenant Padresse de ['instruction de la ligne /*d5*/, comme expliqu6 supra. 

Le programme de Pannexe D se branche done a la ligne /*d5*/ & 
Tissue du sous-programme "fonction_critique". 

Avant Pexecution de Instruction de la ligne /*d5*/, les deux 
premieres valeurs de la pile destructions sont normalement les valeurs 
predetermines 05H et F1H empilees aux lignes /*d24*/ et /*d25*/. 

La ligne /*d5*/ similaire a la ligne /*a1*/ precedemment decrite en 
reference a ('annexe A, represente un ensemble destructions sans rapport 
avec la presente invention. On supposera que ces instructions laissent la pile 
destructions, dans Petat ou elle se trouvait avant la ligne /*d5*/. 

Les lignes /*d7*/ a /*d12*/ sont similaires aux lignes /*c20*/ a 
/*c25*/ decrites precedemment en reference a Pannexe C : 

- depilement dans le registre A aux lignes /*d7*/ et /*d1 0*/; 

- comparaison du registre A, avec les valeurs predeterminees F1H 
et 05H aux lignes /*d8*/ et /*d1 VI ; 

- branchement a Padresse "OSJdllcard" au cours de Pinstruction 
/*d9*/ (respectivement /*d12*/) si le registre A ne contient pas la valeur F1H 
(respectivement 05H) au moment de Pexecution de Pinstruction de la ligne /*d9*/ 
(respectivement /*d12*/). 
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Le sous-programme OS_killcard de traitement d'anomalie est ainsi 
mis en oeuvre, si, par exemple, au cours de I'etape de depilement 1*67*1, on 
depile une valeur differente de la valeur predeterminee F1H. 

On notera que dans ce mode de realisation, la suppression de la 
5 valeur predeterminee 05F1H de la pile d'execution est effectuee apres 
execution du sous-programme "fonction_critique" et non pas suite a une 
attaque ayant lieu lors de I'execution d'un autre sous-programme, cette attaque 
ayant pour consequence I'execution des lignes /*d6*/ a /*d13*/. 

Cette implementation permet done de s'assurer que I'execution 
10 des instructions des lignes /*d67 a /*d13V est effectuee apres I'execution du 
sous-programme "fonction_critique". 

Les lignes /*d14*/ et/*d15*/ terminent le programme de I'annexe D. 

L'annexe E comporte 28 lignes ^instructions numerotees /*e1*/ a 
/*e28*/ d'un programme informatique dont I'execution est securisee . par un 
15 procede de securisation conforme a I'invention dans un mode prefere de 
realisation. 

Les lignes i*e\*l a /*e57 et /*e127 a /*e28*/ sont respectiyement 
similaires aux lignes /*d1*/ a /*d57 et /*d16*/ a /*d327 decrites en reference a 
l'annexe D, a la difference pres que Ton empile dans la pile d'insipuction 
20 I'adresse de la fonction de traitement d'anomalie OS_killcard (lignes /*e207 et 
/*e217) au lieu de la valeur predeterminee 05F1H. 

Cette etape d'empilement est la aussi effectuee pendant 
I'execution du sous-programme "fonction_critique". 

Le programme de l'annexe E se branche done a la ligne /*e57 a 
25 Tissue du sous-programme "fonction_critique". 

Avant I'execution de I'instruction de la ligne /*e57, les deux 
premieres valeurs de la pile d'instructions sont normalement les adresses de 
poids faible et de poids fort de la fonction OS_killcard, ces valeurs 
predetermines ayant ete empiiees aux lignes /*e217 et /*e20V. 
30 Ces valeurs sont depilees au cours de I'execution des instructions 

des lignes /*e77 et /*e87. 



22 



Ce mode de realisation particulier permet de s'assurer que la 
fonction "fonction_critique" est executee apres avoir ete effectivement appelee, 
et non a la suite d'une attaque par generation de faute. 

Dans le cas contraire en effet, le depilement de Tadresse de la 
fonction OS_killcard, au moment inevitable du retour d'execution d'un sous- 
programme, permettrait la detection d'une anomalie de d'execution, notamment 
par la mise en oeuvre de cette fonction. 

Les lignes /*e10*/ et /*e1 1*/ terminent le programme de I'annexe E. 

La figure 1 represente une carte & microcircuit 100 conforme a 
Tinvention dans un mode prefere de realisation. 

Pour simplifier, seul le contenu du microcircuit est represente, et 
ce de fagon sch§matique. 

De fagon connue, la carte & microcircuit selon Tinvention 100 
comporte en outre des Elements materiels et logicieis classiques d'une carte a 
microcircuit, a savoir notamment un support en matiere semi-rigide et des 
moyens d'alimentation. Ces elements ne seront pas decrits ici. 

La carte a microcircuit selon Tinvention 100 comporte des moyens 
de mise en oeuvre d'un procede de securisation tel que decrit precedemment en 
reference aux annexes A & E. 

Dans le mode de realisation prefere dScrit ici, ces moyens sont 
constitues par un processeur 110, associe notamment a une memoire non- 
volatile de type EEPROM, a une memoire vive RAM comportant une pile 
^instructions STACK, et a une memoire morte ROM comportant un systeme 
Sexploitation OS. 

La m<§moire semi-volatile EEPROM comporte notamment les 
programmes des annexes A a E, ces programmes etant lus par le processeur 
1 00 pour leur execution. 

La memoire EEPROM comporte 6galement les deux sous- 
programmes "anomalie" et "OSJullcard". 

Lors de Texecution des programmes des annexes A a E, les 
registres R6, R7 et test sont memorises dans la memoire vive RAM. 
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Dans le mode de realisation decrit ici, le registre A est 
raccumulateur du processeur 110. 
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ANNEXE A 



/*a1*/ 






/*a2*/ 


#pragma asm 


/*a37 


push #00h 


/*a4*/ 


push #01 h 


/*a5*/ 


#pragma endasm 


/*a6*/ 


• ■ • 




1*37*1 






/*a8*/ 


if (test 


= VRAI){ 


/*a9*/ 




#pragma asm 


/*a107 




push #00h 


/*a117 




push #02h 


/*a127 




#pragma endasm 


/*a13*/ 






/*a14*/ 






/*a157 




#pragma asm 


/*a167 




pop A 


/*a17*/ 




XRL A,#02h 


/*a187 




JNZ anomalie 


/*a197 




pop A 


1*320*1 




XRL A,#00h 


/*a217 




JNZ anomalie 


/*a22V 




#pragma endasm 


/*a23*/ 


} 




/*a24*/ 






I*a25*l 






/*a26*/ 


#pragma asm 


1*321*1 


pop A 




/*a28*/ 


XRL A,#01h 


/*a297 


JNZ anomalie 


/*a307 


pop A 




/*a31*/ 


XRL A f #00h 


/*a32*/ 


JNZ anomalie 


/*a33*/ 


#pragma endasm 



I CI UC(JUl 
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ANNEXE B 



/*b17 void function(void) 

/*b27 { 

/*b37 

/*b4*/ #pragma asm 

/*b57 push #HIGH(OS_killcard) 

/*b67 push #LOW(OS_killcard) 

/*b77 #pragma endasm 

/*b87 

/*b97 fonction_critique(); 
/*b10*/ 

/*b117 } 

/*b 1 2*/ void fonction_critiq ue(void) 

/*b137 { 

/*b147 

/*b157 #pragmaasm 

/*b167 pop A 

/*b177 mov R7.A 

/*b187 pop A 

/*b197 movR6,A 

/*b207 pop A 

/*b217 pop A 

/*b227 mov A,R6 

/*b237 push A 

/*b247 mov A,R7 

/*b257 push A 

/*b267 #pragma endasm 
/*b277 

/*b287 } 
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ANNEXE C 

/*c1 */ void function 1 (void) 

/*c27 { 

/*c37 

/*c47 #pragma asm 

/*c5*/ push #05h 

/*c6*/ push#F1h 

/*c7*/ #pragma endasm 
/*ciB*/ 

/*c9*/ fonction_critique(); 
/*c107 

/*c11*/ } 

/*c127 void fonction_critique(void) 

/*c137 { 

/*c147 

/*c157 #pragma asm 

/*c16*/ pop A 

/*c177 movR7,A 

/*c187 pop A 

/*c197 movR6,A 

/*c20*/ pop A 

/*c217 XRL A, #F1h 

/*c227 JNZ OS_killcard 

/*c237 pop A 

/*c247 XRL A, #05h 

/*c25*/ JNZ OS_killcard 

/*c26*/ mov A.R6 

/*c277 push A 

/*c287 mov A.R7 

/*c297 push A 

/*c307 #pragma endasm 
/*c317 

/*c32*/ } 
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ANNEXE D 

/*d17 void function(void) 

/*d2*/ { 

/*d37 

/*d4*/ fonction_critique(); 
1*65* f 

/*d6*/ #pragma asm 

/*d77 pop A 

/*d87 XRL A, #F1h 

/*d9*/ JNZ OS_killcard 

/*d107 pop A 

/*d117 XRL A, #05h 

/*d127 JNZ OS_killcard 

/*d13*/ #pragma endasm 
/*d147 

/71157 > 



/*d 1 67 void fonction_critique(void) 

/*d177 { 

AJ187 

/*d197 #pragmaasm 

/7J207 pop A 

/*d217 movR7,A 

/*d227 pop A 

/*d237 mov R6.A 

/*d247 push #05h 

/*d257 push#F1h 

/*d267 mov A,R6 

/*d277 push A 

/*d287 movA,R7 

/*d297 push A 

/*d307 #pragma endasm 
/*d317 

/*d327 } 



1 Or I W^I^WI 
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ANNEXE E 

/*e1*/ void function(void) 

/*e2*/ { 

/*e3*/ 

/*e4*/ fonction_critique() 
/*e5*/ 

/*e6*/ #pragma asm 

/*e7*/ pop A 

/*e8*/ pop A 

/*e9*/ #pragma endasm 

/*e10*/ 

/*e11*/ } 



/*e12*/ 


void fonction critique(void) 


/*e13*/ 


{ 


/*e14*/ 




/*e15*/ 


#pragma asm 


/*e16*/ 


pop A 


/*e17*/ 


mov R7,A 


/*e18*/ 


pop A 


/*e19*/ 


mov R6,A 


/*e20*/ 


push#HIGH(OS killcard) 


/*e21*/ 


push #LOW(OS_kiI!card) 


I*e22*l 


mov A,R6 


/*e23*/ 


push A 


/*e24*/ 


mov A.R7 


/*e25*/ 


push A 


/*e26*/ 


#pragma endasm 


/*e27*/ 




/*e28*/ 


}" 
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REVENDICATIONS 

1. Procede de securisation de I'execution d'un programme 
informatique, le procede etant caracterise en ce qu'il comporte : 
5 -une etape d'empilement d'une valeur predetermin^e dans une 

pile destructions du programme ; et 

-une etape de depilement de ladite pile, cette etape de depilement 
etant adaptee, le cas echeant, a permettre la detection d'une anomalie de ladite 
execution. 

10 2. Procede de securisation selon la revendication 1, caracterise en 

ce que lesdites etapes d'empilement et de depilement sont respectivement 
associees a des elements d'au moins un sous-ensemble destructions dudit 
programme. 

3. Procede de securisation selon la revendication 2, caracterise en 
15 ce que lesdits Elements sont respectivement une parenthese ouvrante et une 

parenthese fermante dans un systeme de parentheses. 

4. Procede de securisation selon la revendication 2, caracterise en 
ce que ladite etape de depilement est associee a une instruction de retour 
d'execution dudit programme ou d'un sous-programme dudit programme. 

20 5. Procede de securisation selon Tune quelconque des 

revendications 1 a 4, caracterise en ce que ledit programme est ecrit dans un 
langage de programmation, ce langage comportant une premiere instruction 
dont Texecution met en oeuvre ladite etape d'empilement et/ou une deuxieme 
instruction dont Texecution met en oeuvre ladite etape de depilement. 

25 6. Precede de securisation selon la revendication 5, caracterise en 

ce que la deuxieme instruction termine ledit programme ou un sous-programme 
dudit programme. 
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7. Procede de securisation selon I'une quelconque des 
revendications 1 a 6, caracterise en ce que ladite valeur predeterminee est 
representative d'un sous-ensemble destructions critiques dudit programme. 

8. Procede de securisation selon I'une quelconque des 
revendications 1 a 7, caracterise en ce qu'il comporte une etape de traitement 
d'anomalie, mise en ceuvre, si, au cours de ladite etape de depilement, on 
depile une valeur differente de ladite valeur predeterminee. 

9. Procede de securisation selon Tune quelconque des 
revendications 1 a 8, dans lequei ledit programme comporte au moins un appei 
a un sous-programme, caracterise en ce que ladite etape d'empilement est 
effectuee avant ledit appel, et en ce qu'on supprime ladite valeur predeterminee 
de ladite pile pendant I'execution dudit sous-programme. 

10. Procede de securisation selon la revendication 9, caracterise 
en ce que ladite valeur predeterminee est I'adresse d'une fonction de traitement 
d'une anomalie. 

11. Procede de securisation selon I'une quelconque des 
revendications 1 a 8, dans lequei ledit programme comporte au moins un appel 
a un sous-programme, caracterise en ce que ladite etape d'empilement est 
effectuee pendant I'execution dudit sous-programme, et en ce qu'on supprime 
ladite valeur predeterminee de ladite pile apres I'execution dudit sous- 
programme. 

12. Procede de securisation selon la revendication 11, caracterise 
en ce que ladite valeur predeterminee est I'adresse d'une fonction de traitement 
d'une anomalie. 
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13. Support d f informations lisible par un systeme informatique, 
6ventuellement totalement ou partiellement amovible, notamment CD-ROM ou 
support magnetique, tel un disque dur ou une disquette, ou support 
transmissible tel un signal electrique ou optique, caracteris6 en ce qu'il 

5 comporte des instructions d'un programme informatique permettant la mise ne 
oeuvre d'un proc^de de securisation selon Tune quelconque des revendications 
1 a 12, lorsque ce programme est charge et execute par un systeme 
informatique. 

14. Programme d'ordinateur stocke sur un support d'informations, 
10 ledit programme comportant des instructions permettant la mise en oeuvre d'un 

procede de securisation selon Tune quelconque des revendications 1 a 12, 
lorsque ce programme est charge et execute par un systeme informatique. 

15. Entite electronique securisee caracterisee en ce qu'elle 
comporte des moyens de mise en oeuvre d ! un procede de securisation selon 

15 Tune quelconque des revendications 1 a 12. 

16. Entite electronique selon la revendication 15 caracterisee en 
ce qu'elle est une carte a microcircuit. :u 
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